This disclosure relates to debugging circuitry on an integrated circuit chip. The disclosure is particularly relevant to routing debug messages through debugging circuitry of an integrated circuit chip device.
In the past, an embedded system which had multiple core devices (processors, memories etc.) would have been incorporated onto a Printed Circuit Board (PCB) and connected on the PCB via buses. Traffic in the embedded system was conveyed over these buses. This arrangement was convenient for debugging the core devices, because debugging tools such as oscilloscopes and logic analyzers could be attached to the PCB's buses allowing direct access to the core devices.
Market demand for smaller products coupled with advances in semiconductor technology has led to the development of System-on-Chip (SoC) devices. In a SoC, the multiple core devices of an embedded system are integrated onto a single chip. In a SoC, the traffic in the embedded system is conveyed over internal buses, thus connection of debugging tools directly to the system bus is no longer possible. The resulting reduced access coupled with an increasing quantity of data being transported around the chip (due to developments of SoC technology leading to integration of multiple processing cores and higher internal clocking frequencies), has reduced the ability of external debugging tools to find and solve bugs within the system in the timescales demanded by the industry.
Thus, the development of SoC devices required associated development in debugging technology, which lead to the integration of some debug functionality onto the SoC. It is now customary for each core device to have an associated debug unit. Typically, the debug unit can observe the core device, for example by collecting trace data from that core device. The collected debug data is assembled into debug messages and routed through the integrated circuit chip, typically to be funneled off chip via a debug port to external debugging tools. The quantity of debug data collected by the debug units is often huge, and thus high efficiency and low latency in exporting that debug data is important. To achieve high efficiency, it is desirable to maximise the proportion of each debug message which is carrying debug data, and minimise the proportion of each debug message carrying control data. Low latency requires that data is exported shortly after being gathered rather than waiting for significant further data to be buffered. For this reason, simple packet formats are used to transmit debug messages. Typically, the header of each packet has a length field which specifies the length of the packet. Thus, the end of one packet and the beginning of the next packet can be distinguished.
In order to reduce power consumption, typically parts of the SoC are powered down when they are not in use. Thus, at any one time, part of the SoC is powered up and part of the SoC is powered down. A problem occurs if a debug packet is part way through being sent when the unit sending the debug packet powers down. The resulting debug packet is shorter than the length specified in its header. This causes corruption, for example it may lead to downstream units incorrectly identifying where the packet ends. A similar problem occurs when communications are between separate SoC devices of a multi-chip module (MCM) that share a common debug port to the external debugging tools, as one of those SoC devices may be powered down.
One solution to this problem is to ensure from a higher level protocol on the SoC that the unit sending the debug packet cannot power down part way through sending the debug packet. For example, it is known to use a handshake protocol during power down to provide a time period during which messages which are part way through being sent or received are completed prior to power down. However, it may not be possible or desirable to implement such a handshake procedure into the operation of the SoC. For example, the unit sending the debug packet may be a semi-autonomous part of a larger sub-system, and integrating a power-down handshake impractical or undesirable. As another example, the power down capability may have been added as an additional feature or wrapper to an already complete subsystem, and thus integrating a power down handshake procedure impractical or undesirable. In any case, it is undesirable to alter the operation of the SoC for the convenience of the debugging circuitry, because the debugging circuitry is generally intended to passively observe the operation of the SoC.
Another solution to the problem is to use a store and forward mechanism. In other words, the circuitry which routes the debug packets through the SoC collects the whole of a debug packet before routing it on. If this circuitry receives only a partial or corrupted message it may discard it. Thus, the corruption is not propagated downstream. Alternatively, this circuitry may correct the length field in the header of the debug packet to reflect the actual length of the packet. Thus, the corruption is not propagated downstream. However, storing the whole debug packet before routing it downstream introduces an unacceptably high latency into the process of transporting the debug data. Additionally, storing the whole debug packet requires additional chip area to be utilised for the store, and chip power to be used to maintain that store.
Thus, there is a need for a low latency solution to routing debug messages in an integrated circuit chip whose lengths have become corrupted, for example as a result of powering down part of the chip.